User's Choice Windows CD

home *** CD-ROM | disk | FTP | other *** search

/ User's Choice Windows CD / User's Choice Windows CD (CMS Software)(1993).iso / windows5 / wininfo.zip / WW0530.EXE / WW0530T.TXT

Wrap

Text File | 1992-04-07 | 38KB | 789 lines

====================================================================== Microsoft(R) Product Support Services Application Note (Text File) WW0530: SMARTDrive and 32-Bit Disk Access ====================================================================== Revision Date: 4/92 No Disk Included The following information applies to Microsoft Windows(TM) version 3.1. -------------------------------------------------------------------- | INFORMATION PROVIDED IN THIS DOCUMENT AND ANY SOFTWARE THAT MAY | | ACCOMPANY THIS DOCUMENT (collectively referred to as an | | Application Note) IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY | | KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO | | THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A | | PARTICULAR PURPOSE. The user assumes the entire risk as to the | | accuracy and the use of this Application Note. This Application | | Note may be copied and distributed subject to the following | | conditions: 1) All text must be copied without modification and | | all pages must be included; 2) If software is included, all files | | on the disk(s) must be copied without modification [the MS-DOS(R) | | utility DISKCOPY is appropriate for this purpose]; 3) All | | components of this Application Note must be distributed together; | | and 4) This Application Note may not be distributed for profit. | | | | Copyright 1992 Microsoft Corporation. All Rights Reserved. | | Microsoft and MS-DOS are registered trademarks | | and Windows is a trademark of Microsoft Corporation. | -------------------------------------------------------------------- INTRODUCTION ============ Microsoft Windows operating system version 3.1 has a number of enhancements over previous versions that improve both its usability and its performance. Foremost among these enhancements are Windows 3.1's improved features for accessing and utilizing the hard drive of your PC. SMARTDRIVE 4.0 DISK CACHE ========================= Microsoft's first release of the Windows graphical environment included a disk caching program called SMARTDrive 3.03. SMARTDrive has been improved with each subsequent release of Windows and has been entirely redesigned in Windows version 3.1. SMARTDrive 4.0 in Windows 3.1 provides faster and more intelligent disk caching that takes better advantage of the revolutionary way that Windows and Windows- based applications use extended memory. SMARTDrive 4.0 gives Windows 3.1: - Improved performance by speeding up hard disk and RAM access. - Improved stability in 386 enhanced mode by double buffering data when needed. The remainder of this section compares the performance of SMARTDrive 4.0 to SMARTDrive 3.x and illustrates how SMARTDrive 4.0 works at a more technical level. WHAT IS SMARTDRIVE? =================== SMARTDrive is a disk caching program that intercepts system calls to the hard disk to control read/write access to the disk. SMARTDrive intercepts any calls to the hard disk and loads the needed data into a cache it establishes in RAM. (Unless specified otherwise, SMARTDrive automatically determines a reasonable cache size based on the amount of free extended memory available when it initially loads; the maximum amount it will take is around 2 MB.) Subsequent calls to the hard disk are intercepted by SMARTDrive, which scans the cache for the requested data. If the data is already present in the cache, SMARTDrive can access it directly in RAM. If the data is not in the cache, SMARTDrive accesses the hard disk and loads the necessary data into the cache. The least recently used data residing in RAM is cached back to the hard disk to make room for the new data. By loading blocks of data from the hard disk into RAM, SMARTDrive helps decrease the number of calls to the hard disk. This can dramatically speed up applications that repeatedly access the hard disk for data because accessing the hard disk is considerably slower than accessing RAM. Essentially, SMARTDrive attempts to maintain information in RAM that an application needs at any given time from the hard disk. SMARTDRIVE 3.X ============== To understand why SMARTDrive needed to be redesigned, letÆs look at how SMARTDrive 3.x works and examine some of the shortcomings of its design. First, SMARTDrive 3.x is a read-only track cache, which means that it caches on a track basis and for read operations only. This means that the internal data structures of the SMARTDrive program are tied to the logical geometry of the disk (that is, what MS-DOS sees). In the diagram below, you can see that SMARTDrive 3.x caches at the ROM BIOS INT13 level and uses the BIOS-specified disk geometry to decide the size of its caching element (that is, track size). INT13 is the most common method for interacting with hard disks (and has evolved into the industry standard). SMARTDrive under Windows 3.0 can be loaded into either extended memory or expanded memory. Application (Read/Write INT21) | - - - - - - - - - - - - - - - - - | MS-DOS Call HD Driver | HD Driver INT 13 | ---------> SMARTDrive 3.x Chains INT13 ---------< | ROM BIOS | Hard Drive SMARTDRIVE 4.0 ============== SMARTDrive 4.0 is designed as a block-oriented disk cache. It hooks into the system at the MS-DOS device driver level rather than at the ROM BIOS INT13 level (as with SMARTDrive 3.x). Each block device driver on the MS-DOS device driver chain is ôfront-endedö by a SMARTDrive 4.0 module that provides the actual caching. This new design yields the following benefits: - It is independent of the INT13 interface. - It is independent of disk geometry. Application (Read/Write INT21) | - - - - - - - - - - - - - - - | MS-DOS Call HD Driver | ---------> SMARTDrive 4.0 HOOKS Driver ---------< | HD Driver INT 13 | ROM BIOS | Hard Drive Independent of INT13 Interface ------------------------------ Many device drivers do not use the INT13 (BIOS) interface (for example, Bernoulli drives, some hard cards, and many SCSI and WORM drives). This means that SMARTDrive 4.0 can cache these devices, whereas SMARTDrive 3.x cannot. SMARTDrive 4.0 can cache any disk controller that uses an MS-DOS block device driver. Independent of Disk Geometry ---------------------------- Some disk managers and disk controllers use a disk geometry mapping scheme that causes the logical geometry to be different from the physical geometry (for example, many PS/2 systems, Ontrack's Disk Manager, and several disk controllers). The INT13-based disk caches are sensitive to this and often have problems. For example, some disk management software actually changes the ROM BIOS-specified disk geometry, which confuses INT13-based disk caches (including SMARTDrive 3.x). There usually is an interface to determine the true geometry, but this requires detection of the specific disk manager driver and generally complicates the disk cache software. Often, logical tracks actually cross physical track boundaries, causing the track caches to incur performance penalties (intertrack seeks and rotational latencies, for example). To get around the ROM BIOS 1024-cylinder limitation, disk managers and controllers sometimes fold multiple tracks into one logical track. This results not only in problems with the physical track boundaries as noted above, buts forces track caches to have a very large track buffer as well. In some cases, this buffer can be as large as 31.5K and must reside in conventional memory. The design of SMARTDrive 4.0 eliminates this geometry mismatch problem. OTHER SMARTDRIVE 4.0 FEATURES ============================= Write-Behind Cache ------------------ SMARTDrive 4.0 is a write-behind cache, also known as lazy write. A write-behind cache adds significant performance improvements wherever files are being written to disk. For example, an application writes data to what it thinks is the hard disk. SMARTDrive takes this data and places it in the cache, rather than physically writing it to the disk. This write-behind data stays in the cache until one of the following occurs: 1. The cache fills up. The oldest block in the cache is freed up, and if it is write-behind data, physically written to the disk. 2. The system goes idle. SMARTDrive writes the oldest write-behind data block to the physical disk. As long as the system is idle, SMARTDrive continues to write to the disk until all the write- behind data is written. This write-behind data also comes from Windows-based and MS-DOS-based applications that are idle. 3. SMARTDrive detects that you have pressed CTRL+ALT+DEL. When you restart by pressing CTRL+ALT+DEL, SMARTDrive writes all write- behind data to the physical disk. This is a synchronous operation-- SMARTDrive does not give up control until all data is written. 4. A block is older than five seconds. If a block is older than five seconds, it is written to the physical disk. Shrink Algorithm ---------------- Similar to SMARTDrive 3.x, SMARTDrive 4.0 implements a shrink algorithm that frees memory for Windows (that is, the cache set up by SMARTDrive is removed from memory). The difference is that SMARTDrive 4.0 watches for the Windows startup broadcast while SMARTDrive 3.x provides an IOCTL interface. The net effect is identical, but the SMARTDrive 4.0 code is much simpler. Upon exiting Windows, the process is reversed and the memory is reacquired by SMARTDrive 4.0. Automatic Load High ------------------- When an upper memory block (UMB) provider (such as EMM386.EXE) is loaded, SMARTDrive 4.0 (SMARTDRV.EXE) automatically attempts to load itself high. Unlike the Windows 3.0 SMARTDrive, SMARTDrive 4.0 can only be loaded into extended memory. DOUBLE BUFFERING AND BUS MASTERING ================================== The second major benefit of SMARTDrive 4.0 is the protection it provides through double buffering. Double buffering is a response to bus mastering, which is supported by certain (usually older) disk controllers. Bus mastering refers to a situation in which the hard disk controller takes over the bus to directly transfer data to or from system RAM, bypassing the CPU entirely. A problem occurs when Windows 3.x virtual machines and/or popular memory managers (such as EMM386.EXE and QEMM.SYS) are running in virtual 8086 mode. The read or write address that is passed to MS-DOS from the bus master controller is often not the same as the actual physical memory address. This can cause data to be read from the wrong location, or worse, can cause data to be written to the wrong RAM address, resulting in erratic system behavior and potential file corruption. When paging is enabled on an 80386 or faster processor, it is possible for the physical address (the actual location of the memory) to be different from the virtual address (the address that programs are using to access memory). Paging is enabled by all device drivers that can provide load high capability and by Windows in 386 enhanced mode. For example, say SMARTDrive wants to write to an area of memory that has a virtual address in conventional memory, but a physical address in extended memory. When the hard drive controller takes over the bus and transfers data from the UMB to the disk, the controller does not use the CPU, so there is no address translation, resulting in the wrong data being written to disk. To avoid this problem, double buffering copies the data into a buffer in conventional memory and then passes the information to the hard disk controller. So, the virtual address always equals the physical address when using devices that only recognize conventional memory. Installing Double Buffering --------------------------- To install the SMARTDrive double-buffering feature, add the following line to your CONFIG.SYS file: device=c:\windows\smartdrv.exe /double_buffer Including this line does not install the cache, only the double- buffering driver. The cache must be installed from the AUTOEXEC.BAT file or MS-DOS command line. Most disk controllers do not need double buffering. These include all MFM, RLL, and IDE controllers as well as many ESDI and SCSI devices. The Setup program in Windows 3.1 will install the double buffer in the following cases: 1. If the computer has an 80386 or faster processor 2. If 32-Bit Disk Access was not installed in the SYSTEM.INI file (see next section) You should install the double buffer in these cases in the interest of added safety. Another new feature of SMARTDrive 4.0 that helps you determine if double buffering is necessary is the smartdrv command. Once your system is running with SMARTDrive loaded, type "smartdrv" (without the quotation marks) at the MS-DOS prompt and press ENTER. Information similar to the following is displayed: Microsoft SMARTDrive Disk Cache version 4.0 Copyright 1991, 1992 Microsoft Corp. Cache size: 1,048,576 bytes Cache size while running Windows: 1,048,576 bytes Disk Caching Status drive read cache write cache buffering --------------------------------------------------- A: yes no no B: yes no no C: yes yes yes D: yes yes --- For help, type "Smartdrv /?". Note the column labeled "buffering." For each drive that is being cached, one of three values is displayed--"yes," indicating that double buffering is needed; "no," indicating that double buffering is not needed; or "---," indicating that SMARTDrive has not yet determined the necessity of double buffering. If the buffering column displays a "no" for each drive, the double buffer driver is unnecessary, and you can safely remove it from your CONFIG.SYS file. Setting Up SMARTDrive 4.0 ------------------------- The Setup program in Microsoft Windows 3.1 automatically installs SMARTDrive (SMARTDRV.EXE) in the first line of your AUTOEXEC.BAT file. In general, you should let the Setup program configure SMARTDriveÆs cache size for you. However, please note it is critical that SMARTDRV.EXE load after any block devices that reside on your system, such as: - Hard disk partitioning software (for example, DMDRVR.BIN and SSTOR.SYS) - Hard disk drivers (for example, SCSI drives, hard cards, and Bernoulli drives) - Data encryption software (for example, Stacker and DoubleDisk) The configuration of SMARTDRV.EXE is controlled by command-line parameters. Most configuration options can be modified without restarting; however, without the Windows Resource Kit utility SMARTDrive Monitor (SMARTMON.EXE), the configuration cannot be altered while running Windows. Also note that SMARTDrive: - Needs a minimum cache size of 16K. - Creates a cache size of 16K by default if you supply an invalid cache size. - Gives you benefits up to a cache size of 2 MB, whereupon the benefits typically plateau. 32-BIT DISK ACCESS ================== Another new feature of Windows 3.1 is its use of 32-Bit Disk Access. 32-Bit Disk Access is not a program but rather a term used to refer to a system of Windows components working together. The main purpose of these components is to allow Windows to interact directly with the hard disk, bypassing the BIOS, which is normally used for communicating with the hard disk. Under 386 enhanced mode Windows, where 32-Bit Disk Access is supported, you get the following benefits: - Faster hard disk access - Ability to run more MS-DOS-based applications - Faster overall system response, even when running MS-DOS-based applications in the background - More powerful off-the-shelf disk utilities to choose from, since independent software vendors (ISVs) are writing programs that take advantage of this new set of services WHAT IS 32-BIT DISK ACCESS? =========================== - A SYSTEM OF WINDOWS COMPONENTS. Some of these components are called 32-Bit Disk Access devices, but they are useless without the rest of the components to support them. Each of these components is discussed below. - A REPLACEMENT FOR THE HARD DISK BIOS. 32-Bit Disk Access serves as a device driver that interacts with the hard disk controller. 32-Bit Disk Access watches for INT13H calls and handles them if they are for the disk it represents; otherwise, it passes the calls on to the BIOS in the usual way, as if 32-Bit Disk Access were not available. - AN EXACT MATCH FOR THE HARD DISK CONTROLLER (NOT THE SPECIFIC HARD DISK). There are some standards for hardware communication that work on many different controllers. The most widely adopted standard is that introduced by Western Digital in its 1003 controllers. This is the standard supported by Windows 3.1 and more than 90 percent of hard disk controllers, with the exception of ESDI and SCSI controllers. - AN OPEN STANDARD FOR CERTAIN CONTROLLERS. 32-Bit Disk Access is an open standard that is being promoted to all manufacturers of hard disk controllers. This means that every manufacturer has the opportunity to write a device driver that supports 32-Bit Disk Access functionality for its hardware. Many hardware manufacturers are writing 32-Bit Disk Access device drivers that will be available at the time Windows 3.1 ships or shortly thereafter. - AN OPTION, NOT A SYSTEM REQUIREMENT. Without the 32-Bit Disk Access device driver installed, you lose the hardware-access benefits provided by 32-Bit Disk Access, but your system is otherwise unaffected. Windows 3.1 without 32-Bit Disk Access has the same disk access capabilities of Windows 3.0. DISK ACCESS UNDER MS-DOS ======================== The 32-Bit Disk Access feature bypasses the system BIOS to more directly control hard disk access. It acts, in a sense, as the hard disk controller. Before discussing how disk access has changed under Windows 3.1, letÆs look at how MS-DOS handles calls to the hard disk. In the MS-DOS-based PC, when an application wants to read from the disk, it tracks the following sequence: H/W INT21H INT13H I/O ------> -----> -----> ----- ------ ---- ---------- ----- | APP | |MS-DOS| |BIOS| |Controller| ->|Drive| ----- ------ ---- ---------- ----- 1. The application makes an INT21H call to MS-DOS. 2. MS-DOS locates the requested part of the file on the hard disk. 3. MS-DOS issues an INT13H call to talk to the hard disk BIOS. The BIOS contains a program to control each device in the system. 4. The BIOS driver talks directly to the hard disk controller. Each hard disk controller requires its own BIOS driver, but these BIOS drivers are usually not specific to the hard disk itself, but rather to the controller board (or adapter) that connects the hard disk to the rest of the system. This system works well, because MS-DOS is able to identify the files and directories and keep track of their locations, regardless of the type of hard disk MS-DOS is accessing. But, on the other hand, the system BIOS is wholly linked to the hard disk, which provides disk independence for the applications but does not allow the BIOS to differentiate between a call from MS-DOS or a program such as SMARTDrive. But remember that not all disk device drivers reside in ROM. If you purchase an off-the-shelf disk drive and install it, your computerÆs ROM BIOS may not know how to communicate with it. If this is the case, you must install a device driver that is specific to your new hard disk. This additional device driver is usually installed in your CONFIG.SYS file when you install the software that comes with your hard disk. With some devices, such as a CD-ROM drive, a device driver that provides the BIOS interface and INT13H interface to the CD-ROM drive appears in your AUTOEXEC.BAT file. This type of device driver traps INT13H calls to the hard disk and makes sure the calls are understood by the hard disk. Usually, the device driver handles any attempts to access the hard disk; the calls never get passed on to the real ROM BIOS. If the call is not for the device that the device driver represents, then the INT13H call is passed on to the BIOS, where it is handled in the usual way. 32-Bit Disk Access represents a way for Windows to provide a BIOS that better suits customers' device support needs. 32-BIT DISK ACCESS SPEEDS UP DISK ACCESS ======================================== On many machines, the resident hard disk BIOS is slow and inefficient. Since 32-Bit Disk Access is specific to devices, it is often more efficient, leading to very impressive performance increases. 32-Bit Disk Access also allows Windows 3.1 to handle BIOS requests in protected mode, rather than in real mode, which may also speed up disk access. The following diagram charts the flow of calls under Windows in standard mode: H/W INT21H INT13H I/O ------> -----> -----> ----- ------ ---- ---------- ----- | APP | |MS-DOS| |BIOS| |Controller| ->|Drive| ----- ------ ---- ---------- ----- Under 386 enhanced mode Windows, the flow of calls is more complicated: ------------------------------------------------- | Enhanced Mode Virtual Devices | ------------------------------------------------- Protected / \ / \ Mode / \ / \ ----------/-----\------/--------\----------------------------------- Virtual / \ / \ Mode / \ / \ ----- INT21H ------ INT13H ---- H/W ---------- ----- | APP | |MS-DOS| |BIOS| I/O |Controller|-->|Drive| ----- ------ ---- -----> ---------- ----- Windows 3.1 and Windows applications run in protected mode. Windows has to switch back into real mode (or virtual 8086 mode) to run older code (for MS-DOS and the BIOS calls, for example). Switching modes is very time consuming. For example, when a non-Windows application running under 386 enhanced mode tries to read from a file, the following occurs: Windows starts out in virtual mode running the application. Windows makes an INT21H call to read from the file. 386 enhanced mode traps this interrupt and switches to protected mode, where a number of virtual device drivers look at the call and try to qualify it. If none of the device drivers intercepts the call, the call is accepted and is subsequently handed off to MS-DOS. Windows then switches back to virtual mode to let MS-DOS handle the call. MS-DOS reads a particular location on the disk and then generates an INT13H call to talk to the BIOS. Windows in 386 enhanced mode then traps the call again and switches to protected mode to perform certain tasks, hands the call back to the real BIOS, and switches back to virtual mode. The BIOS handles the call and accesses the hard disk controller to set the physical read in motion. Once the BIOS reads the call, Windows goes back to protected mode to perform more tasks and then returns to virtual mode to let MS-DOS see the returned call. Windows returns the INT21H call, switches to protected mode to perform yet more tasks, and then finally switches back to virtual mode to communicate with the application that issued the call to begin with. All this mode switching takes time but is necessary due to the nature of the 80386 processor, MS-DOS, and the PC BIOS. With a 32-Bit Disk Access device installed, Windows can start trapping INT13H calls and handling them entirely in protected mode. With 32-Bit Disk Access, the call diagram now looks like this: ---------------------------- H/W ---------- ----- |Enhanced Mode |32-Bit Disk| I/O |Controller| ->|Drive| |Virtual Devices | Access| -----> ---------- ----- ----------------------------- Protected / \ / Mode / \ / -----------/-------\- ----/--------------------------------------- Virtual / \ / Mode / \ / ----- INT21H ------ INT13H ---- | APP | |MS-DOS| |BIOS| ----- ------ ---- With 32-Bit Disk Access, Windows no longer has to go through two mode transitions--one mode to get to the BIOS and the other mode to get back. Only two mode switches per INT13H call, rather than four, are now being performed. 32-BIT DISK ACCESS SUPPORT FOR NON-WINDOWS APPLICATIONS ======================================================= Sometimes Windows shows an adequate amount of free memory and large Windows-based applications run just fine, yet an "Out of Memory" message is generated when a non-Windows application is started. Also, in spite of the available memory, Windows-based applications may slow down and constantly access the hard disk after a non-Windows application is started. These discrepancies occur because of the difference between virtual memory (which is often large) and physical memory (RAM, which is usually limited). On a given machine, virtual memory might be four times the size of RAM. But, while virtual memory works well for Windows-based applications, it doesnÆt always meet all the systemÆs memory needs for MS-DOS-based applications. Because each non-Windows application runs in its own virtual machine, each application takes up 640K or more of virtual memory. When the virtual machine is actually running, all of the program code needs to occupy RAM. Parts of the non-Windows application cannot be paged out while keeping other parts in RAM, as is the case with Windows-based applications. The virtual machine in which the non-Windows application runs must be treated as a single block. This is true even if the application is currently inactive in the background. With Windows-based applications, most of the program remains resident on the hard disk, while only the parts that are actually being used are loaded in RAM. Problems occur when Windows tries to do this with non-Windows-based applications. If a part of the application that is not currently being used--a data buffer, for example--is paged out, it can always be read back in whenever the application needs to access it. However, if the application makes a call to MS-DOS to read some data from the disk into a buffer, MS-DOS starts handling the call by making a call to INT13H to talk to the BIOS, which in turn talks to the hard disk controller, resulting in the transfer of data into the buffer. So when the application needs to transfer the page into the buffer, which is currently out on disk, the application tries to call MS-DOS to read the page. Because MS-DOS is already occupied, the application canÆt call MS-DOS; and MS-DOS is not reentrant, so the second call from the application fails. Nor can the application have the page read by calling the BIOS, because the BIOS is also in the middle of a call, so it canÆt be reentered either. This situation results in a type of deadlock: the application canÆt let the current call finish until the page is put in the buffer, but the page cannot be placed in the buffer until the current call finishes. The only way to ensure that this deadlock situation does not occur is to make sure that Windows never has to page anything in while the application is in the middle of an MS-DOS or BIOS call. Because Windows cannot predict ahead of time what the application will try to access, the only way to be 100-percent safe from deadlocking is to make sure everything the application might try to access is already in RAM (that is, never paged out to disk). In other words, all 640K-plus of the virtual machine in which the non-Windows application is running has to remain resident in RAM, thereby using up a lot of physical memory. Running several non-Windows-based applications at once uses large amounts of RAM, so you may soon end up with only a small amount of free RAM left for everything else youÆre trying to do, such as run Windows-based applications. When you check the Program Manager About dialog box (from the Help menu), it shows that you have plenty of memory--virtual memory--and you do. But if you try to start another non-Windows application, which requires yet another 640K of RAM, the application won't start. So, Windows starts running sluggishly and/or may generate the "Out of Memory" message. So how does 32-Bit Disk Access help? Windows 3.0 offered a contiguous paging file (which is created with Swapfile) for any pages using the INT13H BIOS calls. Windows 3.1 handles the same task by making calls to the 32-Bit Disk Access system. Unlike MS-DOS or the BIOS, the 32- Bit Disk Access system can queue up multiple requests and is completely reentrant. Windows no longer needs to rely on MS-DOS or the BIOS; so regardless of what the application is doing, Windows can always page calls in from the hard disk. Free from a potential deadlock situation, Windows 3.1 can now make the virtual machines that are running completely pageable. Non-Windows-based applications no longer need to take up so much RAM, since they can now use virtual memory the way Windows-based applications do. When Windows needs some RAM space, it can now page out pieces of these virtual machines. With Windows 3.1 and 32-Bit Disk Access, you can run multiple non- Windows-based applications and Windows-based applications without generating an "Out of Memory" message. When the About box tells you that you have 14 MB of memory, you can actually use all 14 MB for running your applications, whether they are Windows or non-Windows. Improved Performance for Non-Windows Applications Under Windows --------------------------------------------------------------- In the previous example, we saw how 32-Bit Disk Access in Windows can page non-Windows-based applications to free up enough RAM for those applications when they need to use it. The 32-Bit Disk Access feature also improves Windows performance all around, making the system run much more quickly. Switching between non-Windows-based applications by pressing ALT+TAB is faster with 32-Bit Disk Access. Without 32-Bit Disk Access, a non- Windows application can only be swapped out to disk if it is configured to not run in the background. This means when you press ALT+TAB to switch to such an application, Windows has to read the entire program into RAM, causing the task switching to take a long time. When Windows is paging using 32-Bit Disk Access, Windows can load in just the small amount of information that the application is actually using, so task switching becomes almost instant. And, since only a small part of the application needs to be in RAM at one time, Windows may not have to access the hard disk at all. THE COMPONENTS OF THE 32-BIT DISK ACCESS SYSTEM =============================================== The 32-Bit Disk Access system is composed of the following 386 enhanced mode virtual devices: - WDCTRL, which is the 32-Bit Disk Access device that talks to standard Western Digital 1003 or ST506 hard disk controllers (about 90 percent of the installed base). WDCTRL is only installed if Setup detects a compatible hard disk controller. - BlockDev, which coordinates calling block I/O services between devices and the 32-Bit Disk Access devices that provide those services for specific hard disk controllers. BlockDev is always installed. - PageFile, which handles the virtual memory paging file and calls through BlockDev if any 32-Bit Disk Access devices are available. PageFile is always installed. - INT13, which traps and emulates INT13H BIOS calls by calling BlockDev. INT13 is only installed if at least one 32-Bit Disk Access device is present. Because WDCTRL is the only 32-Bit Disk Access device included in the Windows box, the standard Windows components only support 32-Bit Disk Access for Western Digital-standard controllers. When you run Setup, it automatically detects these controllers and adds the following lines to the [386Enh] section of your SYSTEM.INI file: device=*int13 device=*wdctrl If you want to disable 32-Bit Disk Access, start the Control Panel and choose the 386 Enhanced icon, or comment the lines out of your system by placing a semicolon (;) at the beginning of both lines. You do not need to delete any files from your hard disk, as the 32-Bit Disk Access devices are contained within the file WIN386.EXE. 32-BIT DISK ACCESS AND HARD DISK PROTECTION =========================================== Microsoft identified machines where the use of WDCTRL can stop the system. Usually, this is caused by hard disk controllers that appear to be Western Digital 1003 compatible but are really not. WDCTRL has been put though rigorous testing to make sure it is as safe as possible, and is designed with a built-in safety measure--every time it starts, it performs elaborate tests to make sure it can communicate in the same language as the hard disk controller before it attempts to read and write data. WDCTRL starts testing by taking a peripheral look at some data on the hard disk for tell-tale traces of a Western Digital 1003-compatible controller. If the controller passes that test, WDCTRL then starts calling up larger pieces of data to try to elicit the correct response. Finally, after much redundant checking, WDCTRL tries actually reading data from the disk. If it is able to read data, WDCTRL then tries to write data and read it back. Only after the read/write test is passed does WDCTRL continue and start Windows, reassured that it will not cause any catastrophic errors on the hard disk. However, there are still a few exceptions. There are drives that appear to be WD1003 compatible but are not, and which cannot be detected by WDCTRL. In addition, there can be problems even with compatible controllers on some portable computers, specifically those that power down the hard disk to conserve power without telling the running software. If the disk is powered down and then back up while it is being tracked by WDCTRL, the tracking information will be incorrect, and serious damage can result. For these reasons, 32-Bit Disk Access is not turned on by default. When you install Windows, 32- Bit Disk Access is disabled until you make the decision to enable it through Control Panel. Only original equipment manufacturers (OEMs) who preinstall Windows 3.1 on a 100-percent-compatible system can turn 32-Bit Disk Access on before the user receives the system without jeopardizing the userÆs hard disk. When something does go wrong, WDCTRL may do different things, depending on where it is in its verification code. The initial tests have reported WDCTRL as extremely safe. The controllers that WDCTRL fails with are considered incompatible with 32-Bit Disk Access, so WDCTRL simply does not load when it senses these unsupported controllers. This procedure is invisible to the user; he or she just wonÆt receive the benefits of 32-Bit Disk Access. If WDCTRL fails a test after it is installed, Windows displays an error message that warns that something is wrong, most likely that the hard disk might have been damaged, and advises to restart the machine (so that WDCTRL does not load, and 32-Bit Disk Access is disabled). THIRD-PARTY 32-BIT DISK ACCESS DEVICES ====================================== Windows 3.1 ships with only one 32-Bit Disk Access device--WDCTRL. However, Microsoft is working with most of the major hardware and software vendors to help them design 32-Bit Disk Access devices for their products. Concerns regarding distribution and quality of testing for these third-party devices are currently being addressed.